What can we do ( technically ) to get “ the right specification ” ?

One can use formal approaches either post facto to try to show that a program has desirable properties (main of which is that it satisfies a specification); or one can go for correctness by construction. I not only prefer the latter but I have also argued that this is the main way to get formal methods to pay off: there is more mileage in getting a clean architecture than in trying to debug a bad design by retrofitting a proof; I thing this is also a way to choose an appropriate level of formality perhaps using outline arguments and filling in details if doubt arises (see [Jon96]; Jackson and Wing made a similar point in the same journal; also my position paper at the Royal Society meeting in October 2004 – yet to be printed). But how do we know that the specification is right? This is not a trivial question especially with the way computers are today. As computers have become more powerful and less expensive, they have become ever more deeply embedded in the way nearly everyone works. In their short history, computers have moved from batch processors in their own buildings to work tools on every desk (or lap); essential components of administration, retail trade, banking and vehicles; and are on their way to becoming invisible dust sprinkled on who-knows-what. This, in itself, has changed the task of understanding the requirements of a system. Above all, the close interaction of people with computer systems makes it essential that designers consider the whole system when formulating a specification of the technical parts. Model-oriented specification techniques like VDM, Z and B have an enormous amount in common; among other things that this formal methods community shares is the view that one can start with a formal specification and show that a design/implementation satisfies that specification. It is however obvious that, if a specification does not actually reflect the real need, proving a program correct with respect to it is somewhat pointless. Am I arguing in favour of " XP " or fluid prototyping? Certainly not — at least not for most applications. But one might end up there if we decide it's impossible to get the right specification. I strongly believe that, for a crucial set of computer uses, one can –and must– start with a careful process of establishing a good specification (note comments below on " evolution …